docs(halopsa): correct OAuth scopes and login type#246
Open
lc-cbot wants to merge 3 commits into
Open
Conversation
The previous list claimed eight scopes, two of which (read:actions, edit:actions) do not exist — the HaloPSA /auth/token endpoint rejects them as invalid_scope. The remaining six were also non-minimal: edit:tickets subsumes read:tickets, edit:assets subsumes read:assets, and the extension never writes clients or sites so edit:customers is unneeded. Verified against a live HaloPSA tenant by probing each scope in isolation against every endpoint the extension uses; the minimum set 'edit:tickets edit:assets read:customers' authorizes all six extension actions (create_ticket, update_ticket, search_tickets, add_action, link_asset_to_ticket, lookup_client_site) end-to-end. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The "Log on as the Application" instruction was inaccurate: HaloPSA's API Application login type is "Agent" and every request is attributed to a specific agent identity (visible in the id_token JWT issued by /auth/token). Updated the step to instruct picking the agent that should own tickets, actions, and assets created by the extension. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
lc-cbot
changed the title
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two corrections to the HaloPSA extension setup instructions in
docs/5-integrations/extensions/third-party/halopsa.md, verified against a live HaloPSA tenant.1. OAuth scopes
The previous list claimed
read:tickets edit:tickets read:customers edit:customers read:assets edit:assets read:actions edit:actions. Findings:read:actionsandedit:actionsdo not exist — HaloPSA's/auth/tokenendpoint rejects them asinvalid_scope. Actions are a sub-resource of Tickets and are gated by:ticketsscopes.read:ticketsis redundant whenedit:ticketsis granted (verified by probe).read:assetsis redundant whenedit:assetsis granted.edit:customersis unneeded becauseext-halopsaonly does read-only client/site lookups (sites are gated by:customerstoo — there is no:sitesscope).Verified minimum:
edit:tickets edit:assets read:customers.2. Login Type
The previous instruction said "Log on as the Application (the API acts as itself, not as a specific agent)." HaloPSA does not have an "Application" login type — the field's options attribute API requests to a specific agent, which is visible in the
id_tokenJWT returned by/auth/token(it includesname,email, and HaloPSA agentid). Corrected to instruct picking the owning agent.How this was verified
Probed every scope individually against the live HaloPSA tenant, then ran the verified minimum end-to-end against every endpoint the extension uses:
create_ticketPOST /api/Ticketsupdate_ticketPOST /api/Tickets(withid)search_ticketsGET /api/Ticketsadd_actionPOST /api/Actionslink_asset_to_ticketGET /api/Asset,POST /api/Asset,GET /api/Tickets/{id},POST /api/Ticketslookup_client_siteGET /api/Client,GET /api/SiteAdditional findings worth knowing for future docs work:
actionsscope domain — Actions are gated by:tickets.sitesscope domain — Sites are gated by:customers.read:ticketsis enough to create a ticket viaPOST /api/Tickets(returns 201) but is rejected on update with400 "You do not have permission to update this Ticket". Same pattern withread:assets. We still recommendedit:tickets/edit:assetsfor clarity and to cover the update paths./api/Actionswith the wrong scope domain. Worth knowing when triaging.Six test records (3 tickets, 3 assets, tagged
[ext-halopsa scope probe]) were created during verification and cleaned up withDELETEcalls afterwards.A matching update has been made to the
README.mdand thescopefield'sPlaceHolderin theext-halopsarepo (separate change).Test plan
🤖 Generated with Claude Code